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SPECIFICATION 

BACKGROUND OF THE INVENTION 
5 (1) Field of Invention 

The present invention relates to the field of electronic commerce conducted in 
a client-server network environment, typically, the World Wide Web. Specifically, 
the invention relates to issuing performance bonds and guaranties over the Internet, as 
10 in cases where the party to be bonded is an Internet seller or bidder in an on-line 
auction environment. 
(2) Background Art 

The growth of electronic commerce has been accompanied by new risks to 
15 consumers. Enabling long-distance, anonymous transactions between individuals, 
user-to-user auction sites on the World Wide Web have given rise to severe problems 
of fraud and intellectual property piracy. These activities are also common on sites 
operated by fraudulent sellers themselves. 

Various solutions have been attempted. Electronic escrow services, where a 
20 third party is injected between buyer and seller to verify that a quid pro quo exchange 
occurs, represent one proposed solution. But such services, such as escrow.com, have 
proven to be of limited value and have gained only limited market acceptance, mainly 
because escrow services (a) create unavoidable delays in effecting the exchange and 
(b) add significant costs to every transaction, even when the exchange goes well. 
25 Moreover, since escrow transactions must be arranged on an individual basis, the use 
of an on-line escrow approach is simply not feasible for high-volume sellers. 

Another problem plaguing online auctions today is that of "deadbeat bidders, 1 ' 
bidders who win an auction but never pay for the item purchased. Deadbeat bidders 
not only cost the seller a sale to other bidders who would have honored their 
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contractual obligation to pay, but deadbeat bidders also cause sellers out-of-pocket 
expenses, since the auction company's commission typically must be paid by the 
seller whether or not she receives payment from the winning bidder. Escrow does not 
address the problem of deadbeat bidders, nor do electronic payment services, such as 
5 PayPal. 

What is needed is a solution that effectively eliminates the risk of buying and 
selling over the Internet while adding little or no transactional cost in terms of time 
and money. 

Performance bonding is a known means of legally shifting the risk of a given 
10 loss, a performance bond being a contractual agreement between the surety, the 
principal and the obligee whereby the surety agrees to protect the obligee if the 
principal defaults in performing the principal's contractual obligations. Black's Law 
Dictionary, 6 th Ed. 

A guaranty is similar in purpose to a bond. A guaranty is a collateral 
1 5 agreement for performance of another's undertaking in which the guarantor agrees to 
satisfy the debt of another (the debtor), only if and when the debtor fails to repay 
(secondarily liable). 

Collateral is property which is pledged as security for the satisfaction of a debt 
or performance of a principal obligation. 
20 Letters of credit are a known means of facilitating transactions, whereby a 

bank or other institution agrees to honor demands for payment made in compliance 
with specified conditions. 

A penal sum is a monetary sum agreed upon in a bond to be forfeited if the 
condition of the bond is not fulfilled. In this document, the term "coverage limit" may 
25 be used interchangeably with penal sum. 



WO 01/84443 PCT/USO 1/14207 

Automatic means of adding an electronic image and accompanying text to an 
Internet auction listing or other World Wide Web page is also known. For example, 
the company known as Honesty.com enables Internet auction sellers to visit the 
Honesty.com Web site, enter an auction site name, auction number, email address and 
5 password, and then have the Honesty.com logo and a unique "hit counter" added to 
the given auction listing automatically. 

Means of searching the Internet and World Wide Web for infringing uses of 
digital images and text is also known, such as the automated search technology 
designed by iParadigms for plagiarism.org or the techniques known as "digital 
10 watermarking" or "fingerprinting." 

Merchant card services enabling Visa or MasterCard transactions in real-time 
over the Internet are known. 
SUMMARY OF THE INVENTION 
15 The disclosed invention provides an automated, computer-implemented, 

network-based method by which Internet sellers can obtain either a performance bond 
or a guaranty in real time and immediately deploy a unique seal evidencing this 
contractual protection for buyers. The bond and the guaranty are contractual vehicles 
which serve to indemnify buyers against the risk of non-performance or non- 
20 conforming deliveries by sellers. Bonds for bidders, which assure sellers of payment 
when a bonded bidder wins an auction, are also disclosed. 

In the preferred embodiment, the potential bond applicant first visits the Web 
site of the bond/guaranty company ("Company") and registers. The registered user 
then applies for either (1) a general suretyship performance bond which will offer 
25 security to purchasers in all of a seller's eligible Internet transactions up to the penal 
sum for all claims in aggregate or (2) a guaranty for a specific single Internet auction. 
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Upon submission, the seller's application is processed automatically through 
evaluation software with reference to various databases, performing automated 
analysis of the risk-worthiness of the user, the authenticity of the information 
submitted, and other checks. The seller then receives immediate approval or rejection 
5 of the application. If the application is accepted, the terms and price of the bond or 
guaranty are quoted to the applicant. The seller then pays by credit card, and a unique 
seal which identifies the newly formed bond or guaranty is displayed to the applicant. 
This seal can be automatically added to certain auction listings by CGI script, or the 
seller can manually add the HTML code referencing this logo to her HTML 
10 documents, whether these are hosted on her own site or a third party auction site. 

In the preferred embodiment, potential buyers activate their coverage under 

i 

the seller's bond or guaranty by "clicking through" a link in the seal to a page on the 
bonding/guaranty company site and submitting the infoimation requested therein. 
Confirmation of coverage is then sent to the potential buyer by email. Alternately, 
15 coverage can be automatic for anyone who buys from a bonded seller, requiring no 
activation by the buyer. 

If a seller defaults, the buyer submits a claim, including confirmation of 
coverage activation, if required. The Company evaluates the claim and reimburses 
the buyer if warranted. Thereafter, the Company takes appropriate action for 
20 reimbursement from the seller, such as charging the 4 seller's credit card. 

In this way, the present invention offers a more effective, less expensive, 
-infinitely scalable and virtually "invisible" solution to the problem of making the 
Internet a secure marketplace. 

Various security measures for reducing piracy of the seal or otherwise 
25 misrepresenting a seller's status are disclosed. Various revenue models are also 



5 



WO 01/84443 PCT/USO 1/14207 

disclosed which allow shifting of cost to the most efficient payer. A seal which 
includes a "bond margin" counter is also disclosed. 

In one alternative embodiment, the Company's risk is significantly reduced 
through a process by which the bond applicant's credit card used for sequential 
5 preauthorizations that serve to reserve a portion of the funds available in the given 
account as collateral. Other forms of collateral, such as an irrevocable letter of credit, 
can be substituted by special arrangement with the Company. 

In another alternative embodiment, the Company and a third party auction site 
operator work collaboratively through real-time data sharing so as to enable the third 
10 party auction site operator to serve the Company's seal in portions of the auction site 
under the exclusive control of the auction site operator. 

Another significant alternative embodiment provides for the bonding of 
bidders as well as sellers. In this embodiment, bidders can open a deposit account 
with the Company that allows instantaneous payment of a bonded seller at the close of 
15 an auction. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 depicts the basic steps by which an exchange between an Internet 
seller and buyer is transacted. ' 
20 FIG. 2A depicts an exchange between an Internet seller and buyer wherein the 

present invention is used to provide a bond or guaranty. 

FIG. 2B presents a flow chart depicting a high level, general overview of the 
steps involved in guaranty contract formation and claims resolution under the present 
invention. 

25 FIG. 3, included for comparison, depicts the basic steps by which an exchange 

between an Internet seller and buyer is transacted through an escrow service. 
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FIG. 4A depicts a flow chart of a typical site registration process. 

FIG. 4B depicts a uniquely numbered identifying Seal which signifies that the 
given Internet seller is bonded; this Seal is to be displayed in HTML documents 
wherein sale is offered. 
5 FIG. 4C depicts a Seal signifying that the given Internet auction is guaranteed. 

FIG. 5 presents a high level flow chart documenting the process by which an 
application is submitted, evaluated, and processed and the resulting bond or guaranty 
contract, if any, formed. 

FIG. 6 depicts a flow chart documenting the bond application evaluation 
10 subprocess. 

FIG. 7 depicts a flow chart documenting the guaranty application evaluation 
subprocess. 

FIG. 8 depicts a flow chart documenting the process of "flagging" an 
individual. 

15 FIG. 9 depicts a flow chart documenting the process by which a registered 

user's Experience Rating is assigned. 

FIG. 10 depicts an example Verification / Activation Page, to which potential 
purchasers or bidders "click-through" in order to verify that the given seller is bonded 
or the given auction guaranteed and to activate their right to protection under the 
20 given bond or guaranty. 

FIG. 11 depicts a flow chart documenting the process by which a potential 
bidder activates her coverage under a bond or guaranty. 

FIG. 12 A depicts a flow chart detailing the process by which a claim is made 
and resolved. 
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FIG. 12B depicts a flow chart detailing the claims payment and collection 
process. 

FIG. 12C depicts a flow chart detailing the claim dispute resolution process. 
FIG. 13 depicts a high-level map of the databases used in the present 
5 invention, identifying the key relationships between them. 

FIGS. 14A through 14D depict different revenue models to which the current 
invention can be applied. 

FIG. 15 depicts a flow chart detailing the process by which a bond that makes 
use of preauthorized charges to a credit card as collateral is put into effect and 
10 maintained. 

FIG. 16A presents a timeline illustrating the relationship of a bond to the 
Company's risk exposure as a result of that bond. 

FIG. 16B presents another timeline illustrating an example of the relationship 
between the time period during which a bond is effective and the time period during 
15 which a claim against that bond can be made. 

FIG- 17A depicts a map of the database relationship that enables co-operation 
of and data sharing by an auction site and a bonding company. 

Fig. 17B depicts an excerpt from an HTML page that is an auction listing, 
wherein a special seal evidencing a bond is displayed. 
20 Fig. 18 depicts a sequence of five moments in time demonstrating the effects 

of different events on the margin of bond coverage over and above potential claims 
thereon. 

Fig. 19 depicts a flowchart documenting the process by which a bidder is 
bonded and a bidder deposit account is created. 
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Fig. 20 depicts a flowchart that ties together previous discussion by illustrating 
the many different results that can occur after the closing of an auction in the context 
of potential bonding of both sellers and bidders. 

DETAILED DESCRIPTION OF THE INVENTION WITH REFERENCE TO THE 
5 DRAWINGS 

So as to highlight the key components of the present invention, the following 
detailed description uses the example of kn Internet auction as a paradigmatic case of 
electronic commerce. It is known to one ordinarily skilled in the art that Internet 

10 auctions are but a single form of electronic commerce and that the present invention 
applies to other forms. 

It is also known that Internet sellers represent but a single class of 
bond/guaranty purchasers and that the present invention can be readily applied to 
serve any number of "off-line" markets through the collateral reservation process and 

1 5 others described below. 

It is also known to a person of ordinary skill in the art that the Internet 
represents a client-server environment. Thus, when an Internet buyer or seller is 
mentioned in this document, it is understood that, typically, she is accessing an 
HTML document hosted on a server by sending an HTTP request from her client 

20 computer, with Web browser software properly installed, to the server computer 
through the Internet. HTTP server, firewall, data storage and processor hardware 
configurations are known, and server software is assumed to be properly installed on 
this hardware. ; 

All steps in the processes described with respect to the present invention are 

25 executed in software installed on the Company's hardware unless it is expressly stated 
that the step is taken by a human: staff member, applicant, or other person. The 
software to execute these steps is known to one of ordinary skill in the art. Several 
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databases, each of which contain several records with at least one data field per 
record, are depicted. Some data fields serve as repositories for information as it is 
input by a human; other fields contain values which are assigned by a formula which 
references other fields as factors. As is plain to one skilled in the art, the databases 
5 are relational, and most relationships are many-to-many. 

The present invention contemplates a Web site (the "Site") which is operated 
by a bonding/guaranty company (the "Company"), and, in certain embodiments, a 
Web site operated by an auction company ("Auctioneer"). 

By way of introduction, an example of the process by which a typical user-to- 

10 user exchange occurs via Internet auction is depicted in FIGURE 1. The Seller 101 
creates and uploads to the auction site's server an HTML auction listing 102 which is 
then viewed by potential bidders 103. The eventual high bidder 104 places her bid 
through the Web site where the auction listing appears 102. At the close of the 
auction, the Seller 101 sends an email to the Buyer 104 detailing her payment address. 

15 Buyer 104 then sends payment to Seller 101, also conveying her shipping address. 
Buyer 101 then ships item. 

FIG. 2A depicts a similar user-to-user exchange. This time, however, the 
Seller 201 purchases a guaranty or bond from the Company 205 per the present 
invention before uploading the auction listing 202. The transaction is otherwise 

20 similar to that depicted in FIG. 1, except that, when bidding on the auction, the Buyer 
204 also activates her right to protection under the bond or guaranty by clicking on 
the Seal 41 0 or 420 which appears in bonded or guaranteed auction listings. 

FIG. 2B depicts a high-level flow chart of the guaranty process, which is 
essentially similar to that used in bonding. Each of the key steps therein is covered in 

25 greater detail in subsequent discussion. 

10 
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Included for comparison, FIG. 3 demonstrates that using an escrow service 
adds several more steps to the transaction than the present invention requires. 

FIG. 4A depicts the basic steps of registration with the Company Site. For 
reference in later discussion, FIGS. 4B and 4C depict the Seal which plays a key role 

5 in the present invention. This Seal (410 for bonds and 420 for guaranties) includes an 
image (411, 421), preferably a .gif or jpg image, and text (412, 422) which are 
applied to a seller's auction listing or other HTML document to notify the public of 
the bond or guaranty. The means by which these Seals (410 and 420) are created and 
added to HTML documents so as to be viewable by the public are discussed below. 

10 When the hyperlink in the text (412, 422) is clicked, a new browser window is 
spawned, and the Bond Activation/Verification Page (FIG. 10) discussed below is 
displayed therein. A second hyperlink ("Contact Us") appears in this text (412, 422) 
and links to a form on the Site, the Reports Page, which enables submission of a 
report of suspicious activity. 

15 FIG. 5 illustrates a flow diagram documenting the process by which a bond or 

guaranty is applied for, evaluated, legally bound and deployed. Sub-processes are 
broken out in more detail in later figures. 

Having registered with the Site, the registered user logs in 501, views 
information about bonds and guaranties, and selects whether she wants to apply for a 

20 bond or guaranty 502. If the bond choice is selected, the User selects the desired bond 

duration 503 and penal sum from a menu and submits information requested in a 

variety of data fields 504. The requested information includes fields such as: 

al. Principal type of merchandise or services sold, which is selected from a menu 
including computer software, hardware, clothing, music and video media, and other 
25 merchandise categories 

a2. Percentage of sales derived from the category chosen in al 
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a3. Secondary type of merchandise (same menu) 
a4. Percentage of sales derived from the category chosen in a3 
5 b. Expected total revenue from Internet sales 

b2. Last year's total revenue from Internet sales ... 

c. Average # of transactions 

10 

d. User's Social Security # 

e. User's bank 1 

15 f. Bank account number at bank 1 

g. User's bank 2 

h. Bank account number at bank 2 

20 

i. User's employer 

j. Employer's address 
25 k. Employer's city 
1. Employer's state 
m. Employer's postal code 

30 

n. Employer's country 
o. Employer's phone 
35 p. Employer's fax 
q. Employer's email 
r. Employer's web site 

40 

s. Credit Reference 1 (credit card, other loan institution) 
t. Account number for Reference 1 
45 u. Credit Ref 2 

v. Account number for Credit Ref 2 
w. Annual income 

50 
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x. All email accounts used by seller (repeating field) 

y. All web sites (by URL) used by seller (auction sites, personal sites, etc.) (repeating 
field) 

5 

z. Credit card to be charged - type (MC/Visa/AmEx) 
aa. Card number 
10 ab. Card exp. date 

ac. Name on card 

ad. Billing zip 

15 

ae. Answers to various questions such as "Do you sell home-made copies of 
commercial software?" are also requested 

i 

af. Previous bond number, if any 

20 

ag. Password for the previous bond, if any 

Typically, the more credit references and dependable identifying information 
the user provides, the more likely she is to be approved for a bond and/or the less 

25 expensive that bond will be, as discussed below in reference to FIG. 6, since such 
information helps to reduce the Company's risk. If the seller wishes to take advantage 
of instant payment from bonded bidders' deposit accounts per the process described in 
FIG. 19, routing numbers for wire transfers must also be provided. 

When the application is submitted, a new record is created 504 in the 

30 Applications Database. The application is evaluated 505 per the Automated Bond 
Application Review Process depicted in FIG. 6. This sub-process returns a result 509: 
in the case of rejection, the user's browser is directed back to the selection page 502. 
Alternately, (arrow not shown) the user can be sent back to the application page 504 
to correct noted defects in the application. In the case of approval, the acceptance 

35 page is displayed, including a quoted price for the requested bond 511. If the user 
agrees to purchase at the quoted price 513, the charge to her credit card charge is 

13 
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finalized 515, a new record is created 515 in the Bonds Database 1301, (FIG. 13) a 
unique Seal 410 is generated automatically and stored on the Site server 517, and the 
Provisional Bond Contract becomes legally binding 517. The HTML code for the 
Bond Seal 410 is displayed 517 to the applicant so that she can copy this code and use 

5 it in her offers for sale. The HTML referencing the seller's Seal can also be retrieved 
later by the seller visiting her account page on the Site. 

Alternately, (not depicted graphically) the Company can require that the 
bonded seller first submit the URL of each page wherein the Seal will be displayed 
before the HTML code which renders the Seal is made available. Requiring URL 

10 submission of each Web page wherein the Seal is to be displayed may enable greater 
accuracy in Company policing for pirated Seals. 

The Provisional Bond Contract is only valid for a specified period of time and 
is not renewable. It serves primarily to enable instant binding of a bond, a significant 
benefit to sellers, while not exposing Company to extended risk. After the 

15 Provisional Bond is bound 517, a manual review 520 is conducted by Company staff 
of the bond application, who pull credit reports and review submitted information. If 
the seller appears credit-worthy, the Staff authorizes issuance of a Formal Bond 523 
by entering the result in the bond application and finalizing the review process. The 
Formal bond then issues prior to the expiration of the Provisional Bond, thereby 

20 rendering the latter null and void. The bonded seller is automatically notified of the 
issuance of the Formal Bond 523 but is not required to take any further action, since 
supplanting the Provisional Bond with the contractual rights and obligations of the 
Formal Bond does not change the appearance of the Bond Seal 410. If Staff decides 
applicant does not merit the Company's undertaking the obligations of Formal Bond, 

25 Staff enters the result in the appropriate field in the bond application record and 
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finalizes the review process. Thereafter, the Provisional Bond expires, and the seller 
is automatically notified 522. In this case, the Seal image 411, which resides on the 
Company's servers, will be automatically replaced with a new image which indicates 
that the Provisional Bond has expired. 
5 Returning to the top of FIG. 5, if the registered User chooses to apply for a 

guaranty, the first time she purchases a guaranty, she will be required to enter much of 
the same information as is required in the bond application 506. Thereafter, 
subsequent guaranty applications by the same account holder are much shorter so as 
to be more convenient. The abbreviated guaranty application requests the following 
10 information: 

a. Auction site where item to be guaranteed is listed 

b. Auction identification number 1 

15 c. Seller's email address used in that auction listing (used to access the listing) 

d. Type of merchandise being sold (select from menu) 

e. Guaranty amount or estimated closing value 

20 

f. Check box answers to questions such as: "Is all merchandise authentic and 
authorized for sale?" 

g. If credit card is already on file, then the User simply authorizes the charge; if credit 
25 card is not on file, then User provides credit card information. 

While the above fields pertain to a specific auction, the present invention also 
contemplates a single submission form containing multiple repetitions of the above 
fields so that several auction guaranty applications can be submitted at one time, 
30 which reduces unnecessary re-entering of data that does not change from auction to 
auction, such as a credit card number, if such is not already stored. 

Upon submission, the application is processed 507 according to the 
Automated Guaranty Application Review Process detailed in FIG. 7. If the 
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application is approved, then the User is prompted to provide her password for the 
given auction account 510 and email address if the one being used in the given 
auction is different from the one already provided. This password is never stored 
anywhere by the Company and therefore must be entered each time an auction is to be 

S guaranteed. This password is used to gain editing access to the specified auction 
listing so that the Company's CGI script technology can automatically append the 
HTML which produces the Seal 420 to the existing HTML of the specified auction 
listing. If the User is not accepted, her browser is redirected to the begin page 502 or, 
alternately, back to the Guaranty Application page 506 (arrow not shown) to correct 

10 any defects in her application. 

Once the password is submitted 510, which also signifies the applicant's 
authorization to charge her credit card, a new record is created 512 in the Guaranty 
Database, a new, unique Guaranty Seal image 421 is created and stored 512 on the 
Company server, and the CGI script which appends the Seal HTML to the given 

15 auction listing is run 512. If the CGI script successfully adds the Guaranty Seal 
HTML to the specified auction listing, the credit card transaction is finalized 516, the 
Guaranty Contract is consummated 518, and the confirmation page is displayed 518 
in the applicant's browser, informing her that the Guaranty is active, and the Seal 
added to the specified auction. If the CGI script fails, the User is re-prompted for her 

20 email address and password 510. 

FIGURE 6 depicts a flow chart documenting the steps of the Automated Bond 
Application Review Process. Information in newly submitted applications is input 
into this software process 601, and a result — acceptance with price quote 615 or 
rejection 613, with or without reasons — is output. In evaluating the application, the 

25 software will produce a rejection result 613 if any significant fields are left blank 602 

16 
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or if any admissions 603 are made in the application that indicate that the given seller 
is an intellectual property pirate or other illegitimate seller. Next, the contact 
information provided in the application is checked against the information contained 
in all the corresponding fields in all records in the Flagged Individuals Database 1303. 
If a high certainty correlation exists between the contact information provided in the 
application and that in a Flagged Individual record, such as an identical email address, 
then the applicant is consider flagged 604 and is rejected 613. 

If the application survives the initial cuts, a Risk Exposure Level is assigned 
605. This number is the product of a formula which includes several factors, such as: 
the coverage value being requested (higher revenue sellers will yield greater risk 
exposure), the types of merchandise, and the number and verifiability of credit 
references. 

Data is checked to determine whether the applicant has previously been 
bonded by the Company 606. If so, she will already have an Experience Rating, 
which is determined per the Experience Rating Process depicted in FIG. 9 below. If 
the applicant has applied in the past, a manual credit review may have already been 
conducted on that individual and an in-house Credit Rating assigned to her. The 
Experience Rating, if any, and Credit Rating are factored in with the information 
contained in the application itself to assign a Risk Worthiness Level 607 or 610 to 
each application. The Risk Worthiness Level is compared to the Risk Exposure Level 
612, and the application is either accepted or denied. If accepted, a credit card 
preauthorization is performed 609. Provided that the credit card is valid 614, a price 
quote for the bond is output 615, the sub-process depicted in FIG. 6 ends, and the 
main process depicted in FIG. 5 resumes 616. If the application is denied, 
comparison is made between the applicant's Risk Worthiness Level and that required 
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for shorter potential bond durations and lower penal sums to see whether the given 
applicant may qualify for a less risky bond 608. If so, then a new bond duration and 
rate is selected 61 1 for use in the price quote. If the applicant is not sufficiently risk- 
worthy even for a reduced risk bond, then rejection 613 is output 616. 
5 FIG. 7 depicts the Automated Guaranty Application Review Process, which is 

similar to the bond evaluation sub-process. One difference is that the result is strictly 
binary; there is no option of reducing the amount of coverage in order to guaranty a 
non-guaranteeable auction. Also, note that in the preferred embodiment, the prices 
for guaranties are fixed according to the value of the item; thus, a quote is not 

10 necessary, simply the outputting of acceptance and confirmation of price. As an 
alternative embodiment, prices can be set to vary according to the Risk Worthiness 
Level of the applicant, in which case a quote would be necessary. 

FIG. 8 illustrates another supporting process, that by which individuals are 
flagged. The Flagging Process starts with the discovery of information about a given 

15 person 800, through some means other than the filing of a claim, which might be of 
such a discrediting nature that, if true, the Company would not want to issue bonds or 
guaranties to that person. Receipt of such information is a "triggering event" 801. 
For instance, a triggering event could be a notice to the Company by the police 
reporting an intellectual property pirate. 

20 In a particular alternative embodiment (not depicted graphically), the 

Company performs intellectual property monitoring searches on the Internet. Each 
discovery of an instance of piracy would be a triggering event so that searches would, 
over time, create a database of known pirates, a valuable tool in reducing Company 
risk exposure. 
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After the triggering event, the information received is examined manually by 
staff to determine whether the event can be directly attributed to a specific individual 
801. If not, then the triggering event is discarded 808. If so, then the contact 
information identifying that individual, which may be as little as an email address or 
may be a full compliment of contact information with the individual's name, is input 
by staff for automatic searching against the records in the Registered User Database to 
see whether the person may be a registered user 802. If the individual involved does 
indeed appear to be a registered user, then the Experience Rating process 803 depicted 
in FIG. 10 is followed, and the Flagging Process ends 808. 

If the event apparently does not involve a registered user, then a staff member 
investigates 804 to determine whether the damaging information is credible, whether 
the contact information associated with the event is correct (contact info need not be 
complete, just accurate), and whether the magnitude of the event is such that it 
warrants flagging of this individual 805. If flagging is appropriate, then a new record 
is created 806 in the Flagged Individuals Database 1303, and all information available 
on the individual and event are entered in the appropriate fields 807. If flagging is not 
warranted, then the process ends 808, and the information is discarded. 

The Experience Rating Process, depicted in flow chart form in FIG. 9, pertains 
to a triggering event 901 as well. In this case, the triggering event is likely to be a 
claim against a bond or guaranty, but it may also be input from the Flagging Process 
(FIG. 8), into which all reports which are not first presented as pertaining to a 
Registered User are directed. 

Prior to Company's receipt of a triggering event or claim, a Registered User 
record contains a certain value in the "Experience Rating" field which is the product 
of a formula 900. This value grows automatically as the given Registered User builds 
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up "Positive History" by purchasing more and more guaranties or bonds which do not 
result in claims. Specifically, the Experience Rating formula references each Bond 
Database 1301 record and Guaranty Database 1307 record related to the given 
Registered User Database 1308 record so that the value rendered by the formula 
5 automatically reflects the number of that user's bonds and guaranties which have 
resulted in no claims. 1 

Upon the receipt of a triggering event 901, the Company first investigates and 
verifies the event 902 through researching the credibility of the report, if this has not 
already been done (in the case of a claim having already been paid, verification at this 

10 stage is unnecessary). 

Company Staff then evaluates whether the event is credible and damaging 
enough to merit a strike against the user's Experience Rating 903. If not, then Staff 
decides whether to record the event at all 904, either making an entry in the Notes 
Database 910 or ending the process 909. If the event is sufficiently credible and 

15 damaging, the Staff creates 905 a new record in the Notes Database 1311, enters all 
information 905 pertaining to the event, and then assigns a negative value to the event 
and enters 905 this value in the "Negative History" field of the given Notes Database 
record 1311, which field is referenced in the formula which determines the Registered 
User's Experience Rating value, thus resulting in a new Experience Rating 906. If the 

20 new Experience Rating value falls below a predetermined limit as a result of the new 
Negative History 907, then all outstanding bonds and guaranties are automatically 
cancelled, the Seals expired, and the given user is notified 908. 

FIG. 10 depicts an example Verification / Activation Page, which serves a role 
in the Bond/Guaranty Verification & Coverage Activation process depicted in FIG. 
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1 1. The example depicts the Verification/Activation Page for a guaranty, but the page 
for a bond is similar. 

In verifying that a given seller is bonded or a sale guaranteed, the buyer first 
views the Seal (410 or 420) being displayed by the seller 1 101 and then clicks through 
1102 to the verification page (FIG. 10) by clicking on the link included in the text 
(412 or 422) portion of the Seal (410 or 420). Viewing the verification/activation 
page (FIG. 10), the potential buyer evaluates whether this seller is who she claims to 
be or that the auction guarantee matches the auction which the potential buyer would 
like to bid upon and for which coverage is to be activated 1103. If there is not a 
match, the potential buyer may file a report of potential misappropriation of the Seal 
1104. If the there is a match, the potential buyer submits 1105 the information 
requested in the Verification/Activation Page (see FIG. 10), which causes a new 
record 1 106 to be created in the Bond Activations 1302 or Guaranty Activations 1312 
Database. The buyer then receives an email confirming activation of coverage under 
the given bond or guaranty and containing a confirmation code that must be supplied 
in ordeV to file a claim 1106. Alternately, an encrypted attachment (not depicted 
graphically) can accompany the confirmation email for security purposes. 

Thereafter, if the purchase is made 1107, the transaction is undertaken 
between the seller and buyer. If the seller then fails to perform 1108, the buyer 
initiates 1 109 the Claim Process (FIG. 12A). 

FIG. 12A provides a flowchart overview of the Claim Process with reference 
to various sub-processes. Upon failure of the seller to perform 1201, the buyer must 
first request a refund 1202 directly from the seller. Failing to procure a refund 1203, 
the buyer then visits the Claims Page (HTML form hosted on Company site) to 
submit information pertaining to her claim 1204, including proof of her activation of 
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protection under the bond or guaranty, certification that a refund has been requested 
from the seller and that the seller has denied the request, sale price, date, the nature of 
the defective performance, etc. Upon submission, a new record is created in the 
Claims Database 1304. If the information is complete 1205, the information 
submitted is automatically compared to the Registered User database information 
1206 to determine whether the claimant currently owes the Company, e.g., if the 
claimant also has outstanding claims for which the Company has not been re- 
imbursed 1211. If money is owed, the claimant must pay all balances before the 
claim can be processed (1214, 1215, 1216). Once balances are paid, the Company 
staff reviews the merit of the claim 1210. If the claim is sufficient to support payment 
1209, Staff contacts the seller 1213 to request direct refund by seller to buyer. If the 
claim does not support payment, the staff contacts the buyer to see whether the 
deficiency in the claim can be corrected (1208, 1207, 1225, 1212). 

Once the seller has been contacted 1213, she may refund the buyer (1217, 
1218), dispute the claim 1218 or neither. A dispute initiates the Claims Dispute 
Resolution process 1220 detailed in FIG. 12C. If no dispute is made or if claim is 
upheld in dispute, the Claim Payment and Collection Process (FIG. 12B) is followed 
1 224. If the dispute is upheld, the claim is rejected, and the parties are notified of the 
result 1223. 

By the time a claim reaches the process in FIG. 12B (1231), it is ready for 
payment. After the Company has issued payment to the buyer (by check or 
otherwise) 1232, the Staff contacts the seller against whom the claim was made 1233. 
If the seller agrees to reimburse the Company 1235, she sends payment to Company 
1234 and avoids cancellation of her current bonds and guaranties. If she does not so 
agree 1235, then her bonds and guaranties are cancelled 1236 and the credit card 



22 



WO 01/84443 PCTAJS01/14207 
which she has on file is charged for the amount due 1239 as per the Bond or Guaranty 
contract. If the charge is not sufficient to cover the liability, the staff contacts the 
seller for the remaining balance due 1240. If the seller agrees to pay it at this time 
1241, she can still avoid certain complications. If the seller disputes the credit card 
5 charges 1237 or refuses to pay any excess charges 1241, then the Company notifies 
the ISP or auction site involved 1244, suspends seller's account altogether 1243, and 
pursues legal action to collect 1246. 

In all cases, the results are entered 1242 in a new record in the Notes Database 
1311, including an entry in the Negative History field 1242, resulting in a newly 

10 adjusted Experience Rating. 

If a claim is disputed by the seller, the Claim Dispute process depicted in FIG. 
12C is followed. This process gives both the seller and buyer an opportunity to 
present their cases. The Company staff eventually decides whether to strike the claim 
or uphold it, and this result is returned to the main process depicted in FIG. 12 A. 

15 FIG. 13 depicts the core databases involved in storing and manipulating the 

information used in the present electronic bonding / guaranty invention. Principle 
relationships between records in a given database and records in another database are 
denoted with arrows and discussed briefly below. 

Records in the Applications Database 1306 ("Database" hereinafter "DB") 

20 comprise fields for all data submitted by a given registered user for a given 
application. The given application is related to a specific record in the Registered 
Users DB 1308 by way of a unique registered user identification number, which is 
assigned to each record in the Registered User DB at time of creation. As known to 
those skilled in the art, records are said to be "related" when the data in the related 

25 field of a given record in a given first database matches the data in the related field of 
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a given record in a second database. Once a database relationship is properly defined, 
such a data matching will cause data of the two related records to be linked. 

Applications, when successful, result in the formation of new bonds and 
guaranties. Each new record in the Bonds DB 1301 and Guaranties DB 1307 is 
5 related to the record of in the Applications Database 1306 from which it spawned. 

Certain identifying fields, such as email address, in the Applications Database 
1306 may be related to a corresponding field, e.g., email address, in the Flagged 
Individuals DB 1 303 so that applications submitted by undesirable applicants may be 
discovered prior to acceptance as per the Automated Guaranty and Bond Application 

10 review processes in FIGS. 6 and 7. Other fields in the Applications Database 1306, 
wherein the nature of the goods being sold is specified, may also be linked to 
corresponding fields in the Flagged Items DB 1305 to assist in avoiding underwriting 
transactions involving such items. 

Records in the Registered Users DB 1308 are related to several other 

1 5 databases by way of the unique registered user identification number; these related 
databases include the Bonds DB 1301, Guaranties DB 1307, Payment History DB 
1309, Archived Contact Info DB 1310, Claims DB 1304, and Notes DB 1311. 
Typically, the relationship is one to many: one record in the Registered User DB 
1308 relates to multiple payments, multiple bonds, etc., while each payment, bond, 

20 etc., relates to only one registered user (as the Seller). Note, however, that a single 
record in the Notes DB 1311 may relate to multiple records in the Registered Users 
DB 1308. Note also that in order to file a claim, the claimant typically must have 
activated the protection of the bond or guaranty at the time of purchase, thereby 
creating a new record in the Bond Coverage Activations DB 1302 or Guaranty 

25 Coverage Activations DB 1312. At the d time of filing claim, the claimant must then 
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become a registered user, if he or she has not already done so, thereby creating a new 
record in the Registered Users DB 1308. A given record in the Registered User DB 
1308 may therefore relate to multiple claim records 1304 filed by a given user and, in 
a different relationship, multiple claims 1304 filed against that same user. 
5 The records in Bonds 1301 and Guaranties DB's 1312 have a one-to-many 

relationship to the Claims DB 1304 and Coverage Activations DB's (1302, 1312), 
e.g., a single bond may produce multiple claims and activations, but a given claim or 
activation invokes the protection of only one bond or guaranty. 

Less significant relationships are not depicted and should be apparent to one of 

10 ordinary skill in the art of data structure. Similarly, the many fields represented in 
each of the records of the various databases are not denoted by name or content in this 
document but should be apparent. Additional databases not depicted may also be 
employed to enhance the functionality of those depicted, according to the degree of 
sophistication the Company wishes to bring to bear upon the problem of accurately 

15 recording information pertaining to users, bonds and guaranties. For instance, for 
security purposes, the Company may wish to archive IP address information from 
which all bond or guaranty verification/activation click-throughs are received. Also, a 
Reports Database, in which a new record is created any time a report of suspicious 
activity is submitted to the through the Reports Page (not pictured), is contemplated. 

20 FIGS. 14A through 14D depict flow charts detailing different revenue / money 

flow models through which the present invention can be readily funded and deployed 
for the benefit of all parties. The models are essentially self-explanatory. 
FIG. 14A is that which is used in the preferred embodiment. 
FIG. 14B is a promising alternative embodiment, since it provides guaranties 

25 which are free to both buyer and seller. Specifically, the cast of the quantity is paid 
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for by advertisers, who pay for a banner ad 1002 on the Guaranty Verification and 
Activation page 1000. Of course, the seller must still agree to be ultimately 
responsible for any default on his part (141 1, 1414). 

FIG. 14C presents a "buyer pays" model, where the bidder activates protection 
5 if he wants it and is willing to pay for it 1422. This model may well be the most 
efficient, simply because the purchasing decision is placed squarely on the shoulders 
of the party for whose benefit the bond or guaranty coverage exists. 

FIG. 14D presents a model wherein the Auctioneer handles the billing portion 
of the equation 1432, since the Auctioneer is presumably already billing the seller, the 
10 Auctioneer then outsources the rest of the work to Company. Alternately (not 
shown), the entire process can be handled by the Auctioneer providing its own bonds 
and guaranties and otherwise standing in the shoes of the Company. 

It should be noted that different models can be mixed and matched or 
supplemented with other revenue models. 
15 The present invention incorporates several security measures which are not 

graphically depicted. One primary risk to the Company in using the present invention 
comes from misappropriation of the bond or guaranty logo. Sellers who wish to avoid 
liability for claims made by aggrieved buyers but who wish to benefit from the 
appearance of being bonded or offering guaranteed auctions may attempt to pirate the 
20 company Seal and represent that they are covered when they are not. Thus, security 
measures include: 

The Regenerating Seal, A Web browser "reads" HTML documents so as- to display 
images when a proper reference to particular digital image, stored on a connected 
server, is made. The typical HTML code appears in a form similar to this: <img src = 
25 http://www.xxxx.com/image.gif>. 
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In the present invention, the Seal signifying a bond or guaranty includes a 
reference to a unique image, typically, a jpg or .gif file, which is stored on the server 
of the Company. This image is that which is automatically generated for each bond or 
guaranty, and it contains the name, unique ID number, etc., as displayed in FIGS. 4B 
5 (41 1) and 4C (421). As depicted, this Seal image (41 1 or 421) indicates that the bond 
or guaranty it represents only covers purchases or bids made on a specified day. 

The image (41 1 or 421) is regenerated each day at 12:01 am PST with the new 
day's date visible therein and a new, unannounced background and color scheme. The 
new image thai replaces the previous day's image using the same URL or image 
10 address. 

This daily image replacement allows properly referenced images to be 
continually renewed. Images which are not properly referenced, i.e., pirated, do not 
get replaced or updated. Thus, pirated images continue to display an expiration date 
which has already passed and a QoloD^background scheme which is different from all 
15 active bonds and guaranties. This method does not eliminate the possibility of piracy 
but increases its difficulty and detectability. 

Digital watermarking. Each image (41 1 or 421) used in a Seal is encoded so as to 
identify it as an image produced by and belonging to Company. Known search 
software can then be used to track the use of any such images containing this coding 

20 and thereby locate pirated images. 

Text searching. The text (412 and 422) which appears under the Seal image (411 
and 421) is an integral part of all valid Seals (410 and 420). Web text search and 
comparison software, such as that used by iParadigms in its plagiarism.org operations, 
can then be used by Company to detect any publications of this text which are not 

25 authorized. 
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Verification/Activation Page. The Verification/Activation process and page creates 
several protections. First, it puts a certain burden on purchasers to inspect that the 
seller is who he claims to be. Next, if a seller pirates this entire page in order to 
appear to be bonded or to have a valid guaranty, the page itself will appear at a URL 
hosted by someone other than Company, and, if it is referenced anywhere on the Web 
which makes it spider-able, Company text and/or image search software as described 
above will locate this unauthorized page. Even if the fake verification/activation page 
goes undetected, bidders who attempt to activate coverage will not receive a proper 
email confirmation from the Company, and may recognize that something suspicious 
is happening. 

Community self-policing. As the electronic bond or guaranty becomes more familiar 
to the Internet purchasers, these purchasers will become more familiar with the proper 
appearance of the Company Seal and the Verification/Activation Page and will be 
able to recognize more readily when a Seal has expired or been misappropriated or 
when an entire Verification/Activation Page has been pirated and uploaded by 
someone other than Company. Thus, an easy self-policing mechanism is provided in 
each Seal: clicking on "Contact Us" immediately transports the user's browser to a 
Web form where a report can be made. 

"Click-through" tracking. Known software enables tracking of traffic from one 
Web location to another. The Company can employ such software to determine 
where click-throughs are coming from, and these click-throughs can be compared to 
the database of URL's which have been authorized to display the Seal. If a given site 
is displaying the Seal without authority, this information will be automatically 
brought to the attention of Company staff. 

I. Electronic Collateral Reservation Process Alternative Embodiment 
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FIG. 15 presents an overview of a process by which the Company's risk can be 
reduced by continuously preauthorizing a credit card charge in "chain" fashion such 
that there is essentially never a time throughout the duration of a bond when the 
Company does not have a preauthorized charge against the bonded seller's credit card 
in the amount of the full penal sum of a bond. Since this Electronic Collateral 
Reservation Process incorporates many of the processes already described above, the 
flowchart depicted in FIG. 15 is intended primarily to highlight only the differences in 
this alternative embodiment. 

The user begins by completing a bond application choosing a coverage limit 
and specifying whether the bond should be automatically renewed upon expiration 
1501. In this application, she can choose to use one credit card as the "collateral 
card," which will only be charged in the event of a default by the user, and another 
credit card to which payment for the bond will be billed, although the same card can 
be used for both purposes. Provided that the application is complete and otherwise 
acceptable, a charge to the collateral card in the amount of the full penal sum of the 
requested bond will be preauthorized 1502 and a charge to the billing card in the 
amount of the price of the bond will be preauthorized 1502. If both preauthorizations 
are successful, i.e., not declined by the credit card issuer, then the bond application is 
accepted, the charge to the billing card finalized, and the bond contract becomes 
legally binding 1504. If either preauthorization fails or the bond application is 
insufficient on grounds described in reference to FIG. 6 or elsewhere, then the 
application is rejected 1503. 

After a bond application has been accepted, the Company's risk period begins. 
The risk period is discussed in more detail below in reference to FIGS. 16A and 16B. 
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At regular, specified intervals from the beginning through the end of the risk 
period, the Company will follow a "re-preauthorization" procedure 1512. This 
procedure has two basic steps: first, the existing preauthorization, initially made when 
the bond application was accepted, of a charge to the collateral card in the amount of 
the total penal sum is canceled. This step may be achieved by closing out the 
preauthorized charge as an actual $1 charge and then immediately voiding this $1 
transaction. The second step of the re-preauthorization procedure 1512 is executed 
immediately thereafter: a new preauthorization of a charge to the collateral card in 
the amount of the full penal sum of the user's bond is performed. The new 
preauthorization can also be made immediately before the existing one is canceled, if 
the given user's credit limit will allow it. 

This procedure 1512 allows the Company to maintain a virtually uninterrupted 
reservation of a certain portion of the total credit available to the collateral card 
account. This procedure is made necessary by the fact that preauthorizations of credit 
card charges usually expire within a few days of preauthorization. 

Once the risk period has ended 1505, the re-preauthorization cycle 
discontinues 1518. 

Upon the expiration of a bond 1506 for which the user has selected automatic 
renewal 1507, the billing card is charged 1508. If the billing card is declined 1509, a 
suspension notice is sent to the user 1510 indicating that the bond will be suspended 
for lack of payment unless payment is provided within a certain number of days. 
Upon payment, the bond will be reinstated. 

If preauthorization of the collateral card fails 1513, the bond is suspended 
1514 until such time as the user provides new, valid credit card information, at which 
time the bond will be reinstated 1516, provided that the bond itself has not expired. If 
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the user fails to provide a new valid credit card 1513, then the user's Experience 
Rating will be affected, and the user will not be able to purchase additional bonds 
until such time as the failure is remedied 1512. If preauthorization of the collateral 
card is successful 1513 and the risk period has not ended 1505, then the re- 
preauthorization 1512 cycle continues. 

FIG. 16A presents a timeline tying together much of the above discussion. 
The Company's risk period is that time period between the moment of approval of a 
bond application 1601 and the last moment at which filing of a viable, timely claim 
against that bond by an aggrieved buyer is possible 1605. If the Company is using the 
Electronic Collateral Reservation Process described in FIG. 15, it should reserve 
funds in the collateral card account throughout the risk period, and this reservation 
can be released 1606 any time after the risk period has ended 1605. 

In Fig. 16A, a bond application is approved 1601, but the applicant has 
requested that bond coverage not become active until sometime later 1602. The 
applicant has also requested that the bond be automatically renewed upon expiration, 
and thus, in the example of a one month bond model, the bond becomes active 1602, 
expires at the end of one month, and then is automatically renewed immediately 1604. 
This automatic renewal occurs several times until finally the bonded seller requests 
that automatic renewal be discontinued. When the then-current month ends, the bond 
expires and is not renewed, and therefore the bond coverage ends 1603. The 
Company's risk period, however, may not end until sometime thereafter, since claims 
can be filed for bonded transactions that occurred during the active life of the bond 
coverage for a certain period of time after bond coverage has ended 1603, as 
illustrated in the following FIG. 16B. 
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Fig. 16B depicts another scenario in timeline fashion. In this case, the bond 
applicant chooses that the bond become active immediately upon acceptance, and 
therefore the bond coverage period and the risk period begin simultaneously 1610. As 
per the Electronic Collateral Reservation Process, re-preauthorization of the collateral 
5 card charge occurs at regular intervals 1613 thereafter. The bonded seller then lists an 
auction that begins 1611 and ends 1612 during the bond coverage period. Although it 
is not necessary, the Company should probably require that auctions both begin and 
end during the bond coverage period in order for bond coverage to lie. Once the 
auction has ended 1612, the time period allotted for delivery of the purchased item 

10 from seller to buyer begins 1612. A purchaser may not file a claim until this delivery 
period has ended 1614, at which time the claim period begins 1614. The purchaser 
then has a certain number of days during which she can file a claim under the bond, 
after which time the claim period ends 1615, and no more claims can be filed against 
the given expired bond. Thus, in this example, where the bonded seller has run but a 

15 single auction, the Company's risk period ends when the claim period associated with 
that auction ends 1615. Note that the delivery period and the claim period both 
extend well beyond the expiration of the bond 1616, and therefore the re- 
preauthorization cycle 1613 continues also. In the case of bonds which are not 
associated with an auction site, the bond claim period will simply extend for a fixed 

20 period of time after the end of the bond coverage period rather than being tied to any 
transaction. 

If a claim is filed during the claim period, however, then the Company's risk 
period will be extended indefinitely until the claim is resolved, and the re- 
preauthorization cycle will continue accordingly. 
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If multiple claims are made against a single bond, the Company will need to 
make a business decision regarding whether to charge the seller's card the entire penal 
sum and divide the resulting funds amongst claimants, refunding any remainders to 
the card once all claims are extinguished, or to charge the value of each claim as a 
separate charge against the collateral card up to an aggregate sum equaling the penal 
sum. 

D- Integrated Auction Bonding Method 

The preferred embodiment as described above allows the identifying Seal of a 
bond to be added to any HTML page, including both the homepage of the bonded 
seller and auctions she uploads on a third party auction site. However, the security 
measures described may not be enough to prevent unauthorized uses - piracy - of the 
bond Seal. This problem can be partly remedied through the use of an alternative 
embodiment wherein the third party auction site operator, such as eBay (hereinafter, 
"Auctioneer"), itself serves up a condensed version of the bond Seal rather than the 
Seal being served by the Company's servers. Such an approach makes use of the fact 
that certain parts of the HTML page in which an online auction is presented are under 
the exclusive control of the Auctioneer itself, as opposed to the section of content that 
can be manipulated by the auction site user. Thus, if the only legitimate Seals are 
those which are served in an "exclusive control" area, then pirated Seals will be 
obvious and basically pointless. 

Serving of the Seal by the Auctioneer is made possible by the Integrated 
Auction Bonding Method disclosed in the following figures. In this alternative 
embodiment, a high speed data link is established between the servers of the 
Company and those of the Auctioneer. This link allows database replication, meaning 
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that certain fields of records in the Company's bond database are mirrored in a 
separate bond database under the control of the Auctioneer. 

Fig. 17A depicts a simple portrayal of this database relationship. The 
Company's databases, including the Bonds Database 1701 and other related databases 
5 1702 discussed in this document, appear on the left. On the right are the databases of 
the Auctioneer, including the Mirror Bonds Database 1703 and such other databases 
1704 as the Auctioneer uses in its own operations, all of which reside on the 
Auctioneer's hardware. The Company's Bonds Database 1701 is the master database 
from which the Mirror Bonds Database 1703 derives continually updated information. 

10 Only a few fields in the Company's Bonds Database 1701 are replicated in that of the 
Auctioneer 1703, namely: (1) is the bond currently in effect; (2) what is the coverage 
limit of the bond; (3) what is the bonded seller's unique auction site username or other 
control value/ID; and (4), if there may be large delays between updates of the 
information in the Mirror Bonds Database 1703, when is the bond scheduled to 

15 expire. Ideally, this last piece of information need not be stored by the Auctioneer but 
rather the coverage limit field would be continually updated in real-time and reduced 
to $0 immediately upon bond expiration. Additional fields may be stored to enhance 
the functionality, granularity, accuracy or speed of the system as a whole. 

Note that the Company must make a business decision regarding whether to 

20 withdraw bond coverage from auctions that are already running when a bond is 
prematurely canceled (re-preauthorization fails, for instance). 

As with other icons typically served next to the username of a seller, whenever 
that username appears on an auction site, such as the reward stars served next to the 
usernames of prolific sellers on eBay, the condensed bond Seal is called every time 

25 the bonded seller's username appears on the Auctioneer's site. When this call is made, 
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the Auctioneer's databases are queried to determine whether the given seller is 
bonded, and if so, what is the coverage limit of the bond. In cases where the seller is 
bonded, the bond Seal is served. This Seal can simply serve to demonstrate that the 
seller is bonded, or it can display additional information, such as the difference 
between the penal sum and the sum total of aggregated potential claims against the 
bond as determined through the Bond Margin Gauge process described in reference 
FIG. 18 below. 

FIG. 17B shows a fragment of an example HTML page that is an auction 
listing on the Auctioneer's site, which is being operated in cooperation with the 
Company per the Integrated Auction Bonding Method. The seller in this example has 
a unique usemame "JoeSeller" 1711 and has been awarded a user rating 1712 and an 
achievement star 1713 by the Auctioneer. As is typical, the user rating 1712 is a real- 
time updated text value, and the achievement star 1713 is an image file served next to 
the username 171 1 of any sellers to whom it has been awarded. Next to these other 
icons is the Seal 1714, which demonstrates that the given seller is bonded and that his 
bond margin, a dynamically updated, real-time value, is $4690.00. This number is the 
purpose of the Bond Margin Gauge. 

Each time the Seal, including the Bond Margin Gauge, is called to appear in 
an HTML document per request by a client computer to the Company's server, certain 
information is retrieved and processed from the Auctioneer's databases, specifically: 
the bonded seller's coverage limit, the high bid in all currently running bonded 
auctions (including, in the case of a Dutch auction, the top X bids where X is the 
number of items being auctioned in the Dutch auction), and the winning bid in all 
closed bonded auctions for which the risk period has not expired. The sum total of all 
high bids in all currently running bonded auctions and all winning bids in closed 
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auctions for which the risk period has not yet expired is subtracted from the penal sum 
of the seller's bond to leave a difference which represents how much bond 
"headroom" is available under the seller's bond. This number is then displayed in the 
Seal automatically appearing next to the seller's username. This number is useful to 
5 potential bidders, since competing claims against the bond could reduce the 
availability of funds against which an aggrieved buyer could claim in the event of 
default. 

FIG. 18 presents an example of the Bond Margin Gauge in action. On Day 1, 
JoeSeller (1711 in Fig. 17B) has three running auctions, two of which have met the 

10 reserve. The bonded seller's coverage limit is $5000.00, and the sum of the three high 
bids is $310.00. The Bond Margin Gauge therefore reads $4690.00. On Day 2, two 
of the auctions have closed, one of which did not meet the reserve, auction 3. Since 
auction 3 has closed without a winner, the high bid in that auction no longer counts 
against the seller's bond margin. The sum total of the winning bid in auction 1 , which 

15 has closed, and auction 2, which is still open, is $300, and the bonded seller's 
currently available margin as measured by the Bond Margin Gauge is therefore 
$4700. By day 4, auction 2 has also closed with a high bid of $150.00, and the Bond 
Margin Gauge reads $4650.00. 

On Day 93, JoeSeller (1711 in Fig. 17B) lists a new auction which cuirently 

20 has no bids. The risk period for auction 1 has ended, and therefore the winning bid in 
that auction no longer counts against the seller's bond margin. However, the risk 
period for auction 2 has not yet ended, and therefore the seller's bond margin equals 
$4850. By day 95, the risk period for auction 2 has ended, and auction 4 has a high 
bid of $500, resulting in a bond margin of $4500 for the given bonded seller. 

25 

III. Bidder Payment Bonding and Deposit Accounts 
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To this point, the present invention disclosure has dealt primarily with the 
bonding of Internet merchants to protect buyers in cases of merchant default. FIG. 19 
depicts an alternative embodiment of the current invention adapted for bonding 
5 bidders. 

After the user has registered with the Company 1901 and her credit card or 
cards have been preauthorized 1902, the bidder can choose to open a deposit account 
1904, specifying an amount of funds to be deposited with the Company 1905. This 
amount is charged to the bidder's credit card 1905, and the bidder's deposit account 
1 0 shows a credit for these funds. 

It should be noted that a Bond Seal for a bonded bidder preferably appears 
next to the given bidder's usemame, just as Bond Seals appear next to the seller's 
username when a seller is bonded. The Bond Seal used to indicate that a bidder is 
bonded can, but does not have to include a margin counter displaying a value 
15 representing the difference between the bidder's total coverage and the sum total of 
her outstanding bids. The outstanding bids include any winning bids in closed 
auctions wherein it is still possible for an aggrieved seller to claim against the bidder's 
bond. 

It is typically possible for the same auction site account to be used for both 
20 buying and selling activities, and, therefore, one type of Bond Seal appears next to the 
given username when that user is acting as a bidder. Another type of Bond Seal is 
displayed when the given user is acting as a seller, provide, of course, that the given 
user is covered by both an applicable merchant bond and a bidder bond. 

It is to be further understood that the seller can, if required, activate the 
25 buyer's bond upon acceptance of the buyer's bid by linking to the online site by 
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clicking through the Seal and following the coverage activation procedures described 
in greater detail above for activating coverage of the seller's bond by the buyer. 

Whether or not the bidder has elected to open a deposit account, the bidder is 
then given the choice between a preferred bond and a standard bond 1907. The 
5 standard bond, providing but a small amount of coverage, is free and has no set 
expiration date. A preferred bond must be paid for upon initiation and at periodic 
renewals, but the coverage limit available to the bidder is much higher. A preferred 
bond is handled essentially like the sellers' bonds above via the re-preauthorization 
cycle (see 1512 in Fig. 15): the charge for the full penal sum is preauthorized on the 

10 collateral card 1909, the fee for the bond is charged to the billing card 1910, and re- 
preauthorization of the collateral card is repeated periodically thereafter 1911. If the 
bidder chooses a standard bond 1914, the re-preauthorization cycle is not used, but the 
card is checked once every few weeks to see that it remains valid 1915. 

The deposit account is used to allow immediate payments to be made 

15 electronically and automatically by the Company directly to a bonded seller at the 
moment a bonded bidder with a deposit account wins an auction listed by the given 
bonded seller, provided that funds in the deposit account exceed the price of the 
winning bid. 

Fig. 20 provides a flowchart that ties together the complex interactions of the 
20 various embodiments described above when several of these technological methods 
are deployed simultaneously. When an auction closes 2001 wherein the seller is 
bonded 2002, if the bidder is also bonded and has deposited funds in a deposit account 
sufficient to cover the price of the winning bid 2013, payment will be wired 
automatically to the seller immediately after the auction closes 2014. If no such 
25 deposit account funds are available 2013 but the bidder later pays the seller 2015 and 
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the seller delivers 2017, then the transaction has gone well, and the Company does not 
get involved 2004, just as if neither the seller 2002 nor the bidder 2003 were bonded 
at all 2004. If a bonded seller fails to deliver 2017, then the claim process depicted in 
Fig. 12A is followed. In cases where the bidder is bonded 2003/2016 but fails to pay 
2005/2015, the seller must file a claim against the bidder's bond during the claim 
period 2006. If the bidder does not correct her default 2007, the seller must deliver 
the item purchased in the auction to the Company 2008. Upon satisfactory delivery, 
the seller will be paid by the Company 2009, and the bidder's collateral card charged 
2010, both for the amount of the bid price and for a default premium whereby the 
Company profits from having served as a surety for the defaulting bidder. Thereafter, 
the purchased item can be sent to the bidder by the Company if desired. If the 
bidder's collateral card is declined 2010, then the bidder is contacted, and the 
Company's chosen collection methods are employed. 

Alternately (not depicted), the seller can sell the purchased item to the next 
highest bidder in case of default by the winning bidder, if this next highest bidder can 
be found, in which case the Company would reimburse the seller her transaction costs 
in finding another buyer and charge the defaulting bonded bidder for these costs in 
addition to a premium. 

Another alternative (not depicted) provides that when sellers are listing 
auctions on the Auctioneer's site, they are offered the option to allow only bonded 
bidders, or only bonded bidders with deposit accounts, to bid on the auction. The 
Auctioneer's databases will then be checked when a bidder places a bid to see 
whether that bidder is bonded before the bid will actually be placed. 

Another option that can be offered to sellers by the Auctioneer at listing time 
is to allow automatic discounts « 2% off the price of winning bid, for instance - for 
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any bidders who are bonded. Some auctions already allow sellers to offer discounts 
to the first bidder in a given auction. 

Various embodiments of the of the present invention have been described 
herein. It should be understood by those of ordinary skill in the art, however, that the 
above described embodiments of the present invention are set forth merely by way of 
example and should not be interpreted as limiting the scope of the present invention, 
which is defined by the appended claims. Many other alternative embodiments, 
variations and modifications of the foregoing embodiments that embrace various 
aspects of the present invention will also be understood upon a reading of the detailed 
description together with the Figures. For instance, it will be understood that features 
of one embodiment may be combined with features of other embodiments while other 
features may be omitted (or replaced) as being nonessential to the practice of the 
present invention. 
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What is claimed is: 

1 . A method for providing bond or guaranty coverage, the method 
comprising the steps of: 

providing an online site having a server operable to receive a bond or 
5 guaranty request; 

receiving from a first entity a bond or guaranty request; 
issuing a bond or guaranty in response to bond or guaranty request; and 
generating a unique identifier suitable to display on a computer 
network evidencing to a second entity that a bond or guaranty is in effect with 
10 respect to transactions involving a first entity. 

2. The online method described in Claim 1 , comprising the further step 
of: 

activating the bond or guaranty coverage upon receipt of a request for 
15 coverage from a second entity. 

3. The online method as described in Claim 1 , comprising the further 
steps of: 

receiving registration information from a first entity; and 
20 registering the first entity in a Registered User Database. 

4. The online method as described in Claim 3, comprising the further 
steps of: 

providing a communication to a first entity confirming registration; 
25 providing a secure code to the first entity; 



41 



01/84443 PCT/USO 1/14207 

receiving the secure code back from the first entity; and 
confirming registration by matching the secure code received from the 
first entity with the secure code provided to the first entity. 

5. The online method as described in Claim 1, wherein the step of 
generating a unique identifier comprises further the step of: 

posting the unique identifier to a computer network site displaying 
transactions involving the first entity. 

6. The online method as described in Claim 5, wherein the step of posting 
the unique identifier comprises: 

posting the unique identifier to an online auction site displaying the 
first entity's auction listing, the unique identifier evidencing that the auction 
listing is covered by a bond or guaranty. 

7. The online method as described in Claim 6, wherein the step of posting 
a unique identifier comprises applying a .gif or jpg image to the first entity's 
auction listing. 

8. The online method as described in Claim 2, wherein the step of 
activating the bond or guaranty coverage comprises the steps of: 

providing a link between the unique identifier and the online site; 
receiving a coverage request from the second entity; and 
providing a confirmation of coverage in response to the submitted 
coverage request. 
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9. The online method as described in Claim 8, wherein the step of 
receiving a coverage request further comprises the steps of: 

entering the coverage request into an Activations Database; and 
5 activating the bond or guaranty coverage. 

10. The online method as described in Claim 1, comprising the further step 
of: 

processing a bond or guaranty request, the processing step comprising: 
10 creating a record of request in an Applications Database; and 

reviewing the bond or guaranty request to assign a risk 
worthiness level based on a credit rating for the first entity. 

1 1 . The online method as described in Claim 1 0, wherein the step of 
1 5 processing a bond or guaranty request further comprises the steps of: 

evaluating a request using an Automated Bond or Guaranty 
Application Review Process, the Review Process comprising the steps of: 
determining whether a request is complete; and 
evaluating a request for information that requires rej ection of the 
20 request. 

12. The online method as described in Claim 10, wherein the step of 
reviewing the bond request to assign a risk worthiness level further comprises 
assigning a risk exposure level based on bond or guaranty coverage value 
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being requested and/or the characteristic of the transaction for which coverage 
is requested. 



1 3. The online method as described in Claim 1, wherein the step of 
5 generating a unique identifier further comprises the step of: 

generating a Bond Margin Gauge, the Bond Margin Gauge 
corresponding to the difference between the bond or guaranty coverage limit 
and a value assigned to the transactions involving a first entity. 

14. The online method as described in Claim 13, wherein the step of 
generating a Bond Margin Gauge further comprises: 

posting the Bond Margin Gauge on an online auction site, the Bond 

i 

Margin Gauge providing a value equal to the difference between the first 
entity's bond or guaranty coverage limit and the sum total for the high bid in 
each of the first entity's auction listings that are presently open. 

15. The online method as described in Claim 1, comprising the further 
steps of: 

providing a link between the unique identifier and the online site; and 
20 displaying on the online site a verification page indicating that the first 

entity has bond or guaranty coverage. 

16. An online method to enable a first entity to serve as surety for a second 
entity, the method comprising the steps of: 
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providing an online site having a server operable to receive a bond 
request; 

receiving a bond request; 

conducting a preauthorization of a charge to a specified account; 
issuing a bond, wherein the first entity serves as a surety; and 
conducting a re-preauthorization of a charge to a specified account 

after the occurrence or nonoccurrence of a specified condition and/or a period 

of time has passed. 

17. The online method described in Claim 1 6, comprising the further step 
of: 

charging payment to the specified account to renew the bond following 
expiration of the bond. 

18. The online method described in Claim 1 7, comprising the further step 
of: 

generating an unique identifier suitable to display on a computer 
network evidencing to a third entity that a bond is in effect with respect to 
transactions involving a second entity. wherein the first entity serves as a 
surety. 



1 9. The online method described in Claim 16, comprising the further step 
of: 

activating the bond or guaranty coverage upon receipt of a request for 
coverage from a third entity. 
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20. The online method described in Claim 18, comprising the further step 
of: 

activating the bond or guaranty coverage upon receipt of a request for 
5 coverage from a third entity. 

21. The online method as described in Claim 17, comprising the further 
step of: 

communicating a suspension notice to the first entity if the bond 
10 renewal is unsuccessful. 

22. An online method for providing online bond or guaranty coverage, the 
method comprising the steps of: 

providing an online site having a server operable to receive a bond or 
1 5 guaranty request; 

issuing a bond or guaranty to a first entity in response to a bond or 
guaranty request; 

generating a unique identifier suitable to display on a computer 
network evidencing to a second entity that a bond or guaranty is in effect with 
20 respect to transactions involving a first entity; and 

receiving a claim from the second entity in response to a first entity 

default. 



23. The online method described in Claim 22, comprising the further step 
25 of: 
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activating the bond or guaranty coverage upon receipt of a request for 
coverage from a second entity. 



24. The online method as described in Claim 22, comprising the further 
5 steps of: 

entering the claim into a Claims Database; and 
paying claim to the second entity. 

25. The online method as described in Claim 22, comprising the further 
10 steps of: 

providing a link between the unique identifier and the online site; and 
providing a location on the online site for the input of coverage request 
information. 

15 26 - The online method as described in Claim 23, comprising the further 

step of: 

providing a confirmation of coverage to a second entity upon 
activation of coverage. 

20 27 - The online method as described in Claim 24, wherein the step of 

paying the claim to the second entity comprises: 

receiving claim information from a second entity; 

creating record of claim information in a Claims Database; 

evaluating claim information; and 
25 providing a claim payment to the second entity. 
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28. The online method as described in Claim 27, wherein the step of 
evaluating the claim information comprises the further step of: 

assessing claim information provided by second entity to determine 
5 whether the second entity owes any financial obligations to the online site. 

29. The online method as described in Claim 22, comprising the further 
step of: 

notifying first entity of a second entity claim; 
10 providing a claim dispute process for first entity, the claim dispute 

process comprising: 

requesting information from the first entity that supports dispute; 

receiving information from the second entity to rebut the first entity's 
information; 

1 5 upholding or striking claim in response to information provided by the 

first and/or second entity. 

30. An online method for providing online bond or guaranty coverage, the 
method comprising the steps of: 

20 providing an online site having a server operable to receive a bond 

request; 

receiving a bond request for an online buyer; 
registering the online buyer with the online site; 
providing the online buyer with the ability to select a standard bond or 
25 a preferred bond; and 
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issuing a bond in response to the bond request by the online buyer. 



31. The online method described in Claim 30, comprising the further steps 
of: 

5 accepting payment for the standard or preferred bond; and 

providing an online seller with payment in the event of a default by the 
online buyer. 

32. An online method for providing online bond or guaranty coverage, the 
10 method comprising the steps of: 

providing an online site having a server operable to receive a bond or 
guaranty request; 

receiving a bond or guaranty request from a first entity; 
processing the bond or guaranty request; 

15 issuing a bond or guaranty to the first entity in response to the bond 

request; 

displaying an unique identifier to an online auction site carrying the 
first entity's auction listing, the unique identifier evidencing that the first 
entity's auction listing is covered by a bond. 



20 



25 



33. The online method described in Claim 32, comprising the further step 
of: 

activating the bond or guaranty coverage upon receipt of a request for 
coverage. 
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34. The online method as described in Claim 32, comprising the further 
step of: 

providing an HTML code to the first entity for the unique identifier. 

35. The online method as described in Claim 32, comprising the further 
step of: 

receiving a URL for each Web page the unique identifier is to be 
displayed on before providing an HTML code to the first entity for the unique 
identifier. 

36. The online method as described in Claim 32, wherein the step of 
processing a bond request comprises further the step of: 

creating a record of request in an Applications Database. 

15 37. An online method for providing online bond or guaranty coverage, the 

method comprising the steps of; 

providing an online site having a server operable to receive a bond or 
guaranty request; 

receiving from a first entity a bond or guaranty request; 
20 issuing a bond or guaranty in response to bond or guaranty request; and 

generating a unique identifier suitable to display on a computer 
network evidencing to a second entity that a bond or guaranty is in effect with 
respect to transactions involving a third entity. 
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38. The online method described in Claim 37, wherein a fiist entity and 
third entity are the same entity. 



39. The online method described in Claim 37, comprising the further step 
5 of: 

activating the bond or guaranty coverage upon receipt of a request for 
coverage from a second entity. 

40. The online method as described in Claim 37, comprising the further 
10 step of: 

processing a bond request received from the first entity, the processing 
step comprising: 

creating a record of request in an Applications Database; and 
reviewing the bond request to assign risk worthiness level based on a 
1 5 credit rating for a third entity. 

41 . The online method as described in Claim 37, wherein the step of 
generating a unique identifier further comprises the step of: 

generating a Bond Margin Gauge, the Bond Margin Gauge 
20 corresponding to the difference between the bond or guaranty coverage limit 

and a value assigned to the transactions involving the third entity. 

42. The online method as described in Claim 41, wherein the step of 
generating a Bond Margin Gauge further comprises: 
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posting the Bond Margin Gauge on an online auction site, the Bond 
Margin Gauge providing a value equal to the difference between the first 
entity's bond or guaranty coverage limit and the sum total for the high bid in 
each of the third entity's auction listings that are presently open. 

43. The online method as described in Claim 41, wherein the step of 
generating a Bond Margin Gauge further comprises: 

posting the Bond Margin Gauge on an online auction site, the Bond 
Margin Gauge providing a value equal to the difference between the first 
entity's bond or guaranty coverage limit and the sum of the sum total of the 
high bids in each of the third entity's auction listings that are open and the sum 
total of the winning bids in each of the third entity's auction listings that have 
closed, but for which the period during which a claim can be filed has not 
closed. 

44. The online method as described in Claim 13, wherein the step of 
generating a Bond Margin Gauge further comprises: 

posting the Bond Margin Gauge on an online auction site, the Bond 
Margin Gauge providing a value equal to the difference between the first 
entity's bond or guaranty coverage limit and the sum of the sum total of the 
high bids in each of the first entity's auction listings that are open and the sum 
total of the winning bids in each of the first entity's auction listings that have 
closed, but for which the period during which a claim can be filed has not 
closed. 
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45. The online method as described in Claim 10, comprising the further 
step of: 

adjusting bond coverage based upon changes in the assigned Risk 
Worthiness Level. 

5 

46. The online method as described in Claim 1, comprising the further step 
of: 

processing the first entity's guaranty request, the processing step 
comprising: 

10 creating a record of request in an Applications Database; and 

reviewing the guaranty request to assign risk worthiness level based on 
first entity's experience or credit rating. 

47. The online method as described in Claim 1 1 , wherein the step of 
15 evaluating the request using an Automated Bond or Guaranty Application 

Review Process comprises the further steps of: 

creating a Flagged Database containing information on a given entity 
that warrants rejection of a bond or guaranty request by that entity; and 
comparing request information input by the first entity to the 
20 information stored in the Flagged Database. 

48. The online method as described in Claim 1, comprising the further step 
of: 
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providing an Experience Rating for the first entity having a value that 
indicates the level of bond or guaranty issuance to the first entity that does not 
result in claims by a buyer. 

49. The online method as described in Claim 1, comprising the further 
steps of: 

receiving claim request against the first entity from the second entity; 
evaluating claim request against first entity; and 
paying claim to second entity. 

50. The online method as described in Claim 49, comprising the further 
step of entering claim request into a Claims Database. 

51. A method for displaying on an online auction site the coverage limit 
remaining a given bond or guaranty, the method comprising the steps of: 

generating a Bond Margin Gauge, the Bond Margin Gauge 
corresponding to the difference between the bond or guaranty coverage limit 
and a value assigned to the transactions involving a first entity on an online 
auction site, and 

displaying the Bond Margin Gauge on an online auction site. 

52. The online method as described in Claim 51, wherein the step of 
generating a Bond Margin Gauge a Bond Margin Gauge providing a value 
equal to the difference between the first entity's bond or guaranty coverage 
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limit and the sum total for the high bid in each of the first entity's auction 
listings that are presently open. 



53. The online method as described in Claim 51, wherein the step of 
generating a Bond Margin Gauge comprises a Bond Margin Gauge providing 
a value equal to the difference between the first entity's bond or guaranty 
coverage limit and the sum of the sum total of the high bids in each of the first 
entity's auction listings that are open and the sum total of the winning bids in 
each of the first entity's auction listings that have closed, but for which the 
period during which a claim can be filed has not closed. 

54. A method for conducting an internet auction having the auction bonded 
through the auction site, the method comprising the steps of: 

providing a first server operable to host an online auction, the server in 
communication with a first database having information relating to whether 
bonds are in effect; and 

displaying an image in an area on the online auction under exclusive 
control of operator of the first server, the image evidencing that at least one of 
the parties to the auction is bonded. 

55. The method described in claim 54, comprising further the step of: 
providing an informational link between the first database and a second 

database, whereby the information in the two databases is continually updated 
to mirror each other. 
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56. A method for conducting an online auction, the method comprising the 
steps of: 

providing a server configured to host an online auction; 
providing a deposit account into which a first entity can make a 
deposit of funds; 

receiving electronic funds transfer information for a second entity; and 
after an auction has closed, transferring funds from the deposit account 

of a first entity to an account specified by a second entity using electronic 

funds transfer information provided by the second entity. 



57. A method of collateralizing a credit card, the method comprising the 
steps of: 

receiving credit account information from a first entity; 

conducting a preauthorization of a charge to a user's account; 

after an occurrence or nonoccurrence of a specified condition and/or a 
period of time has passed, voiding the preauthorization and conducting a re- 
preauthorization of a charge to the same user's account. 

58. A system to enable online purchasing by a principal of a surety bond, 
the system comprising: 

a server computer in communication with a client computer, the server 
computer operable to receive bond or guaranty request from a client computer; 

a server computer program operable to process, evaluate and approve a 
bond or guaranty request, wherein a bond or guaranty request is approved and 
made legally binding without human review of the request. 
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59. A method for preventing the piracy of an online image, the method 
comprising the steps of: 

generating a first image for display at a specified image address, the 
first image displaying a first expiration date; 

generating a second image that is different than the first image, the 
second image displaying a second expiration date; 

replacing the first image with the second image, so that the second 
image displays the second expiration date at the specified image address. 

60. A system for bonding an auction listing on an online auction site, the 
system comprising: 

a server operable to host an online auction site, the server being 
connected by a computer network to a client computer, the server operable to 
receive bond or guaranty request information from the client computer; 

a database connected to the server, the database adapted to receive 
bond or guaranty request information; 

a first computer program operable to process bond or guaranty request 
information; and 

an unique identifier displayed by the server indicating the existence of 
bond or guaranty coverage for a given auction listing. 

6 1 . The system claimed in Claim 60, wherein the unique identifier appears 
in HTML pages served by the server computer. 
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62. A method for providing a surety bond to an Internet auction user, the 
method comprising the steps of: 

providing a server operable to receive a bond application; 

assigning at least one value to the bond application, the value being 
based upon information provided in the bond application; 

issuing a provisional bond when the value meets a predetermined 
threshold; and 

after the issuance of a provisional bond, issuing a formal bond 
following manual review of the bond application. 

63. A method for conducting an Internet auction, the method comprising 
the steps of: 

providing a server operable to host an Internet auction; 

providing a database adapted to retain information relating to bonding 
of users of an Internet auction site; 

discounting the closing price of the auction when the winning bidder in 
the auction is bonded. 

64. A method for providing electronic payment services to users of an 
Internet auction site, the method comprising the steps of: 

providing a server operable to receive a first entity's auction site user 
account information; 

providing the first entity with a deposit account uniquely related to the 
first entity's auction site user account; 
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providing a server operable to receive second entity's auction site user 
account information; 

retaining electronic funds transfer information that is uniquely related 
to the second entity's auction site user account; 

providing a server configured to receive information indicating that an 
Internet auction has closed; and 

providing a computer program that electronically transfers funds from 
the first entity deposit account to the second entity after an auction has closed 
and the first entity is the winning bidder in an auction and the second entity is 
the seller. 

65. A method for providing electronic payment services to users of an 
Internet auction site, the method comprising the steps of: 

providing a server operable to register a first entity, the first entity 
being an auction site bidder; 

opening a deposit account specific to the first entity; 

providing a server operable to monitor the status of an Internet auction; 
at the close of the Internet auction, providing funds from the first entity's 
deposit account to a second entity where the second entity is a seller on an 
Internet auction site and the first entity is the winning bidder. 

66. The method described in claim 65, comprising the further step of: 
conducting a preauthorization of a charge to the first entity's credit 

card; and 
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charging the first entity's card to provide funds to the first entity's 
deposit account. 



67. The method described in claim 65, comprising the further steps of: 
providing the first entity with the option of obtaining a preferred bond 

or standard bond. 

68. The method described in claim 65, wherein the step of providing funds 
to the second entity comprises transferring the funds from the first entity's d 
deposit account to the second entity immediately after the auction closes. 
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